硅谷技术新焦点：摆脱缝合怪的多云设计，才是云计算的归宿
云成本已经成了一个不可忽视的问题。硅谷顶尖风投 a16z 说：“不使用云计算，你就是疯了；坚持使用云计算，你也是疯了。”
现在，在寒冬面前，云成本和云安全问题就更显得严重。如果不想“下云”，那么必须考虑用精细化运营来节省成本。而绝大部分使用云服务的公司都在使用多云，在这种情况下，一种“新”的多云构架被逐渐认为是应对当前挑战的解决方案，2022 年，戴尔科技集团、HPE、红帽、Snowflake 等行业领导者们不断地围绕它发起认真、具有前瞻性的讨论。
这种基础架构是当今多云和混合计算模型的自然演变，在云原生的基础上，同时提供跨云服务、提供抽象和一致性的多云服务，简化环境并降低成本。它被誉为“云计算的下一个阶段”，但不管用什么来定义它，都足以让大家思考一个问题，为什么我们需要一个用于混合多云世界的新架构？
尽管不同企业对多云的实践有各自的理解，但是使用多云策略在近几年已成为大多数企业在商业上心照不宣的默契。据统计，目前全球 81% 使用云服务的公司或组织正在使用多云，而其中 90% 的企业表示多云能帮助他们更好的实现业务目标。现在，许多大企业和政府机关早已将业务分布在不同的云服务商上。比如苹果公司为了处理不断增长的服务需求，在使用亚马逊和自建数据中心之外，也在不断增大使用谷歌云的预算，仅 2021 年就增加了 50%，达到了 3 亿美元。
回顾过去，这几年云计算圈最受瞩目的大战无疑是云巨头们争夺价值 100 亿美元的美国国防部的联合企业基础设施合同 (The Joint Enterprise Defense Infrastructure，简称 JEDI)。虽然早在2019 年微软已击败亚马逊，与国防部签订了这一合同，然而随之而来长久的诉讼和政治纠纷也将这场合作拖向了泥潭。这场持续了 3 年的纷争以合同取消而告终。然而，这并不意味着国防部放弃了对企业级的云能力的需求。美国国防部随即又迅速提出了新的合同，即“联合作战人员云能力”（Joint Warfighter Cloud Capability，简称 JWCC）。
纵观美国国防部的申明，我们能看到相较于 JEDI，JWCC 最大的改变是它将会是一个“多供应商，采用多云策略”的合同。我们认为这也体现了 2018 年到 2022 年这几年间云计算市场在商业上的一个重大的改变：使用多云策略正逐渐取代使用单一供应商，成为越来越多的企业和政府部门在进行数字化转型时的常态。同时，也有越来越多的云服务商与云原生生态选择拥抱这一趋势，以保持在多云时代的竞争优势。在国内，同样的趋势也在上演，我们能看到越来越多的政务云平台也开始向多个供应商招标，并向多云架构转型。
在云数据应用开发领域，一匹值得关注的黑马是Snowflake。作为云原生时代发展起来的技术，Snowflake 的技术演化也体现了在多云时代商业化需求的变化方向。
虽然近两年，Snowflake 开始野心勃勃地向数据湖等数据分析细分领域进军，但它起初是基于 AWS S3 和 EC2 的数仓服务。随着多云时代到来，和大多数 SaaS 提供者一样，数据延迟，合规性和数据读取成本开始成为 Snowflake 客户的痛点。由于在设计之初其计算、存储和服务层就进行了分离的架构， Snowflake 相继在 Azure 和 Google Cloud 上提供了一致的服务，以吸引基于不同生态的客户。
而随着多云的不断发展，越来越多的客户将不同的业务分布在多个云服务提供商处运行，此时他们面对的问题是这些业务在产生的数据往往很难在多个公有云之间共享或统一处理，这些数据已经形成了“数据孤岛“。为了打破不同云服务商之间的壁垒，Snowflake 在去年引入了对外部表 (External Table) 的支持，使得企业内部或与第三方能够支持在多个公有云提供商之间的数据共享，并和内部表进行联合分析。
图 1：Snowflake 将多云支持扩展至自有云
然而仅仅在公有云上支持数据共享并不能悉数满足企业的要求，一个不可忽视的现实是企业有许多业务和数据必须保留在自有或私有云上。因此在今年的 Snowflake Summit 上，Snowflake 宣布了将在未来把对外部表的支持扩展至任何 S3 标准兼容的私有云存储服务上。用户能够将私有云以及公有云上无法迁移的数据引用至 Snowflake，并能和已导入 Snowflake 的数据共同分析。
纵观 Snowflake 在多云时代中的发展历程，我们可以总结多云时代企业的需求是如何发展的：首先企业需要这些服务能在不同云服务商上提供，无论企业原有的生态和数据合规性需要数据产生端在哪个供应商处，企业都能够基于这些服务开展业务。同时需要能够支持企业已有的自有或私有基础设施，保证企业私有数据不必复制到公有云处。在此基础上能够打破不同服务商之间的壁垒，实现数据互通。这样无论公有云和私有云上的、企业一手的或者第三方提供的数据能全面地被数据分析业务所使用，并进行统一的管理。同时企业也能更灵活的利用多云架构中各种平台上的计算资源。
虽然 Snowflake 敏锐的察觉到了市场的需求并且推出了一系列变革性的技术积极拥抱这些变化，然而这仅仅是在云数仓这一细分领域踏出的第一步。我们认为，真正要从根本上解决企业在多云时代面临的诸如数据互通和体验不一致等问题，企业的多云策略必须从事实多云（By Default）向真正的多云架构 (By Design) 转变。
基于多云策略的架构之所以成为绝大多数企业数字化转型时的新路标， 因为在“上云”过程中往往会遇到不可忽视的痛点：成本。
和大家印象相反的是，公有云优势是”弹性”以及“弹性”对于启动新业务的总体开销下降。而对于绝大部分客户的成熟”现金牛“业务来说，总拥有成本（TCO, Total Cost of Ownership）是更重要需要面对的问题。而使用单一提供商带来的供应商锁定的问题 (lock down)，即我们经常说到的“店大欺客”，实际上是一个无解商业困境。那么由于成熟业务和相关数据迁移到其他供应商的成本高昂且周期较长，只依赖于一个供应商会使企业失去基础架构的议价权，无法完全掌握自己的命运。一个著名的的例子是 Netflix，作为亚马逊最大的客户之一，他们大部分的在线服务和分析业务都依赖于亚马逊所提供的服务，因此逐年上涨的使用成本也成为他们财报上的一大压力。所以越来越多的企业在设计新业务架构时，也逐渐将不同阶段起步的业务分布在不同的基础设施和供应商处，从而一定程度缓解单供应商锁定的问题。
而且在事实多云时代，选择公有云还是私有云的争论已变得无关紧要。“小孩子才做选择题，成年人当然是全都要”，基于多云的架构使得企业能够充分平衡云原生私有云和公有云解决方案的优劣势。例如借助多云架构，成熟”现金牛“业务可以部署于自有云原生基础设施之上，从而降低在数据安全性和低延时流水线上的成本。而另一方面通过借助多个公有云的服务，新产品和业务能够“弹性“的拥抱新技术和生态，并同时借助多个公有云也能使企业在满足合规性的同时低成本快速将业务拓展至别的国家和地区，从而在市场上取得先机。
但是在现实世界中，几乎所有的企业在其数字化转型之初是从单云或是早期不成熟的多云起步，大家只是被动的在业务需求产生时才考虑增加新的供应商，签订新的服务合约，增加新的基础设施架构。然而由此产生的多云架构往往只能被称作为事实上采用了多云，也就是企业只是在单纯的混合使用多个云供应商的服务，而并未考虑这些云服务商之间的服务如何协作，也未如何给企业自己业务呈现统一的服务接口，更致命的是数据也只是根据业务发展的轨迹留在不同的云上。那么这样的架构就不是真正的从多云设计出发的架构，而是一个简单的“缝合怪”。
企业在向云数字化转型过程中通常有几种典型的架构，比如，在《6 Multi-Cloud Architecture Designs for an Effective Cloud Strategy》 一文中，以作者提到的较为复杂的应用程序现代化为例，他建议将多应用云原生化，作为一个组合部署到多云，如下图所示：
图 2：应用程序现代化迁移策略
然而如果仅仅应用这种多云策略，这仍然是一种事实多云。其主要问题在于，随着多云市场的逐渐成熟，云的概念本身在不断扩展。除了公有云和企业自有设施 (On premise) 外，主机托管云（Co-location）能够帮助企业内部 IT 可以从繁重的运维中解放，减小运维数据中心的成本。同时，随着我们进入 5G/IoT 时代，边缘终端数量和部署场景的爆发式增长，去中心化架构的流行，边缘云也成了企业云版图中不可或缺的一部分。因此在考虑多云架构时，除了传统的企业自有云和公有云外，也需要考虑不同平台的特征来为数据和应用选择其最合适的数据平台，最大程度节省企业的成本。
其次是数据在这些平台上的互通性问题。资深数据行业专家戴夫·麦克罗里（Dave McCrory）曾经提出过数据引力（Data Gravity）这个概念。数据引力是指随着某个数据平台上积累的数据越来越多，越来越多的应用和新数据会继续被已有数据“吸引”，从而继续停留在这个平台上。而采用事实多云的企业往往是根据业务启动时的合约选择数据存储的服务商。由于不同供应商之间往往无法提供原生的数据互通性。因此随着业务生成的数据越来越多，数据在平台上的引力也将越来越大，使得业务仍然难以迁离，仍然会被锁定在某个供应商上。
同时，虽然应用云原生化了。但是部署、运营和管理如此多样的基础设施是非常复杂的。企业的应用程序和数据驻留在多个云环境中，这些环境之间提供的基础服务、API 等很难保持一致，从而导致应用开发和运维的成本与日俱增，并没有达到通过多云节省成本、提高效率的目的。
由此可以看出，虽然事实多云一定程度上缓解了企业的在上云过程中的成本问题，然而如果企业只是采用事实多云，为了管理多个供应商、多份服务合同、多个基础设施架构，所需花费的人力和运维成本仍然将十分高昂。因此，如何从计算和存储角度提供真正的多云架构，是解决企业上云痛点的关键。
我们认为，为了解决事实多云带来的这些困境，一个从平台端到存储和计算端，真正的从多云出发（By Design）的架构应该符合以下几个特征：
首先，从数据保护和数据存储开始，实现从边缘、自有设施、主机托管和公有云上的统一数据管理。通过创建一致的数据层，允许云原生环境下的应用横跨所有云生态，允许客户选择云环境和基础设施来支持业务运营。
其次，应该提供多云环境下一致的运维体验。K8s 已经成为了云原生时代事实上的标准，AWS EKS、Google GKE、Azure AKS、RedHat Openshift、SUSE Rancher、VMWare Tanzu 是市面上最主流的商用 K8s 平台。如何能和这些 K8s 平台集成，让企业能在本地和公有云、主机托管商、边缘云的环境中享受到一致的体验，是提升运维效率的关键。
再者需要考虑新兴的边缘云的特性。和其他云相比，边缘云单个规模会小得多，并且由于去中心化的架构设计，通常包含边缘云的多云架构需要管理的系统也会比其他云更加多，基础设施也不像数据中心那样便于维护。这也意味着边缘云的基础设施和计算、存储服务都需要提供足够的弹性和可伸缩性，同时能提供统一的自动化远程管理。
最后，还需要提供一个统一的数据迁移解决方案。企业的各种数据应该能够自由的在公有云、自有云、主机托管商、边缘云之间按需流动。
总之，一个真正的 By Design 的多云架构必须能够解决客户目前面临的数据孤岛和运维复杂性问题。多云应该能让数据、计算在统一运维的基础上根据需要自由的流动，核心是将选择权交还给客户。
我们以一个大数据分析平台为例，介绍一下在多云场景下，如何设计一个 By Design 的多云构架，让客户拥有灵活选择权和体验一致性。
图 3：多云数据分析平台
在这个多云场景下，由于 K8s 平台的介入，可以让客户不用再关心各云间计算平台的区别，从而简化并统一了运维的工作。客户可以灵活使用上述各种类型的云支持企业的不同业务。
边缘云主要承载 IoT 场景和边缘计算场景，负责对 IoT 设备的数据进行预处理，提供基础设施。
自有云主要负责本地数据的实时分析、实施平台的集中化管理以及计算平台的编排。主机托管私有云主要负责远端的用户数据分析工作。
公有云则主要负责在私有云算力无法满足时，对算力进行补充。也承载数据的归档和数据检索等。
理想情况下，企业应用的开发和部署应具有相当的灵活性，以减少对于云平台的耦合。现代应用应该选用更加灵活的存储作为主存。
考虑到数据迁移的成本，与其拷贝全量数据到多云，不如选择重要的数据在多云之间互通。
在现实的企业应用中，无状态的计算端可以容易的做到在多云之间进行迁移。而对于有状态的存储端，想要做到灵活可迁移却并不容易，而且它们的管理面、数据面的 API 也各不相同。AWS、Azure 和 Google 都提供了基于 Spark 大数据平台方案，但是在存储层，则基于自家的存储产品给出了不同的方案：
然而，实际上云厂商提供的存储层设计未必满足所有客户的需求。例如，从底层存储中提取数据作为其他用途，或者对存储层问题进行排查，面对不同的构架设计和存储系统，客户需要不少的成本去解决问题。如果客户想更进一步，在多云间实现数据的互通，则需要更多的开发时间和成本。而在一些更高级的存储功能上，甚至需要客户具备存储领域的专业知识，例如保证数据一致性、版本控制、跨云访问数据的安全等等。
可以看到，从事实多云到真正为多云设计架构的转变过程中，在存储层的设计上有不少的挑战，在设计新的多云存储构架时，应该考虑到以下若干方面。
首先，我们要考虑存储管理面的统一：各家公有云厂家提供的管理界面各不相同，企业客户需要分别单独管理它们。为了实现存储管理面上的统一，可以在它们的管理界面之上加入一个统一的管理层，运行于企业私有云。此外，它也负责协调各云间的访问控制和鉴权；在多云间同步数据的时，负责存储互联时的 TLS 证书和密钥等。在这个方面实际上也已经有很多软件产品，例如 BMC Helix Multi-Cloud Service Management、IBM Multicloud Manager、Red Hat CloudForms…
其次，我们要考虑存储接口上的统一，从而在应用层不必为各云厂商分别适配。在企业级应用领域，无论开源或者闭源领域，都对对象存储表现出浓厚的兴趣，相比于传统的块存储、文件存储，对象存储具备更好的灵活性。如上文提到 Snowflake 直接利用 S3 存储作为外部表的支持，以及大数据领域逐步从 HDFS 转向对于 S3a 的支持，可以预见，对象存储在未来有着不错的发展前景。在诸多的对象存储协议中，无论在开源界还是私有云对象存储产品领域，S3 协议无疑是最流行且被广泛支持的。因此，在这个示例构架中，我们选择 S3 协议实现数据层接口一致性，对于那些不支持原生 S3 协议的公有云厂商，可以在它们之上加入一个轻量级 S3 协议转换层。
再次，我们要考虑如何实现数据的灵活迁移，数据要流动起来才有价值。假设我们已经统一了存储数据层的 API 接口，那么让数据在多云间同步就有了良好的基础。我们可以在每个云中部署一个 data movement 服务，根据设置好的同步策略，实现特定重要数据的云间同步。例如，基于 data movement 服务实现一个多云间共享且满足一致性协议的对象桶，在保证了多云间数据可靠性的同时，客户通过任意接入点，都能得到这个对象桶的统一数据视图。
最后，数据的安全也是越来越重要的一环，包括存储安全和传输的安全：
存储安全：客户需要按需启用云的服务端加密。而业界的一个明显趋势就是加密硬件的使用越来越普遍，在操作系统和数据介质端都需要有不同等级的专门芯片来进行数据加密。
传输安全：需要考虑到多云数据同步服务的传输加密，包括启用客户端证书、TLS 等。
多云已成为一种现实。在企业“上云”初期，使用多个不同的云已经能够帮助企业和政府 IT 部门缩短开发流程，快速拓展业务，并且避免单一供应商锁定，从而在一定程度节省资产和运营开支。然而随着云原生生态的不断发展，数据产生端变得更多样化，不同平台，云供应商之间发展方向也很难保持一致。因此在使用事实 (By Default) 多云几年后，企业会发现其数据总拥有成本并未降低太多。同时数据作为企业资产的价值越来越大，正如《经济学人》所说，“数据是未来的石油”。越来越多的企业已经意识到有相当大一部分的业务和相关的数据只有打破不同平台和云提供商的壁垒，流动到其最合适的位置，才能发挥最大的价值。因此企业在设计多云架构时，也开始逐渐思考怎样能够从事实上的多云，转变为真正为多云设计 (By Design) 的架构，达到真正降本增效的目的。
随着多云的版图将越来越多的平台囊括其中，放在云原生生态圈面前的是如何在拥抱真正为多云设计的架构时兼顾“鱼”（提供一致性的体验）和“熊掌”（让客户拥有足够多样选择）的课题。在计算端，首先需要解决的是支持更多数据产生平台和数据类型。例如在今年的峰会上，Snowflake 除了宣布了对企业自有平台数据的支持，同时也宣布了对基于 Apache Iceberg 的表类型的支持计划。我们认为它已经在拥抱真正为多云设计的架构上踏出了第一步。
而在存储端，S3 已经成为云原生对象存储事实上的统一标准。而如何在多样的数据中心和云提供商上提供统一管理，数据能灵活流通的存储层，同时让对象存储和云生态更有机地结合，则是各存储提供商下一步的方向。戴尔科技集团也为顺应多云存储一致性的需求，首先推出了其下一代云原生软件定义对象存储 ObjectScale 提供统一的 S3 存储抽象，然后通过和 Snowflake 的合作，进一步简化企业大数据流水线在多云环境中落地难度。 并同时积极拥抱开源浪潮，更进一步在“data virtualization”层次提供更好的开源 + 商业的完整生态。例如在最近火热出炉的 Apache Iceberg 1.0.0 release 中，社区就首次加入了对 ECS/ObjectScale 的原生支持。
我们相信，随着多云架构的发展，越来越多的云原生生态开发者将会发现，如何能兼顾这两者会是关乎其数据服务是否能在未来企业在真正从多云出发的架构中能有一席之地的关键课题，也是赢得企业用户订单的关键点。“by design“的多云时代已经到来。
作者简介：
滕昱，戴尔科技集团 OSA 软件工程高级总监，Pravega 中文社区创始人。
丁辰瑜，软件开发经理，来自戴尔科技集团 OSA 分布式对象存储研发团队，专注于分布式对象存储在混合云、多云时代的一致性模型及数据流动性的研究和开发。
商小乐，高级主管软件工程师，负责戴尔科技集团 OSA 分布式对象存储元数据、多云体系构架设计和开发。
孙骜，技术专家，负责戴尔科技集团分布式对象存储系统架构设计和开发。
马斯克称 Twitter 可能破产；Meta 暴裁 1.1 万人，小扎承认犯了错；GitHub 年度报告：印度开发者增速超中国 | Q 资讯
动动嘴就能写代码了！Copilot测试新功能“嘿，GitHub”，告别键盘编码
和Rust一样好，编程更安全？三年实践、员工态度反转，英伟达用 SPARK 换掉 C